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Utan bra krav 
blir det inga bra 
system. Och det 
galler att arbeta 
med kraven under 
ett belt projekt. 
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BETYDELSEN 

Undersokningar visar att 50 procent 
av allt merarbete i utvecklingsprojekt 
beror pa problem med kravhantering. 
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MANNISKORNA 

Det storsta problemet med kravhan¬ 
tering ar att de inblandade i projekten 
inte kommunicerar med varandra. 
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HANDGREPPEN 

Sa har gar det till om man vill und- 
vika problemen med kravhantering. 

Det galler att undvika missforstand. 
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LANGSIKTIGHETEN 

Krav ska inte bara formuleras i borjan 
av ett projekt. De maste hanga med 
anda tram till systemforvaltningen. 

METODERNA 

Krav hanteras olika med olika metoder. 
De nya agilemetoderna innebar stora 
forandringar i kravhanteringen. 

VERKTYGEN 

Utbudet av kravverktyg ar stort, men 
ibland klarar man sig med en ordbe- 
handlare och lite kreativitet. 
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Den stora 
hemligheten 
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Kravhantering ar oerhort viktigt men 
det ar inget de fiesta pratar om. Den 
som vill forbattra arbetet med att 
utveckla system bor borja med att se 
over sin kravhantering. 


”Hela 31,1 procent 
av alia projekt 
slutfors aldrig. 

52,7 procent av alia 
projekt kostar 
189 procent av 
de uppskattade 
kostnaderna” 


KRAVHANTERING, eller require¬ 
ments management som det 
heter pa engelska, ar kanske 
inte sa sexigt. Det ar i alia fall 
inget omrade som diskuteras 
pa kafferasten. 

Anda vet de fiesta som arbe- 
tar pa kontor att det ar viktigt 
att definiera vilka krav som 
ska stallas pa ett system, eller 
pa vad som heist, som ska ska- 
pas. 

Bilden av kravhantering i 
dag ar for det mesta att man 
helt enkelt skriver ner sina 
krav pa till exempel ett system 
pa en lang lista. 

Sedan bockar utvecklarna 
av kraven ett efter ett och nar 
systemet ar klart uppfylls alia 
krav och alia ar nojda. Latt som 
en platt. 

man borjar inse att det har sat- 
tet att arbeta har stora bris- 
ter, inte minst inom it. Varfor 
skulle annars sa manga projekt 
misslyckas? 

I artiklarna som foljer i 
det har kompendiet beskrivs 
alternativa satt att arbeta. 

De kanske mest uppseende- 
vackande exemplen i Sverige 
under senare ar pa att traditio- 
nell kravhantering inte racker 
till ar ett antal projekt for att 
infora affarssystem. 

Forsakringskassan och 
andra har gatt pa miljonsmal- 
lar, for att inte saga miljard- 
katastrofer, nar de inte lyckats 
infora affarssystem pa ett bra 
satt. 


TEXT: 

LARS DANIELSSON 

ILL: 

KJELL ERIKSSON 


de INSTALLERADE systemen har 
helt enkelt inte uppfyllt de 
krav som formulerats. 

Och, kanske annu viktigare, 
de krav som har formulerats 


har inte varit de ratta kra¬ 
ven. 

I de har exemplen ar det inte 
ens fragan om att skapa nya 
system. Man ska installera sys¬ 
tem som redan finns och gora 
installningar for dem. 

hur VIKTIGT ar kravhantering? 
Om vi koncentrerar oss pa 
systemutveckling finns det 
en undersokning som mer an 
andra satt fokus pa den fra¬ 
gan. 

The Standish Groups rap¬ 
port som publicerades 1995, 
kallad Chaos Report, ar ingen 
rolig lasning for den som ar 
intresserad av systemutveck¬ 
ling. 

Till att borja med kom man 
fram till att hela 31,1 procent av 
alia projekt aldrig slutfors. 52,7 
procent av alia projekt kostar 
189 procent av de uppskattade 
kostnaderna. 

Det uppskattas att ameri- 
kanska foretag 1995 skulle 
lagga ner 81 miljarder dollar pa 
utvecklingsprojekt som skulle 
laggas ner. 

Som en jamforelse uppskat¬ 
tas det att amerikanska foretag 
skulle lagga ner 59 miljarder 
dollar pa projekt som skulle 
slutforas. 

en dyster bild av systemut- 
veckling och det blir varre. 
De projekt som faktiskt slut¬ 
fors av stora amerikanska 
foretag har bara 42 procent 
av de ursprungligen definie- 
rade funktionerna. Endast nio 
procent av projekten i stora 
foretag betecknas som fram- 
gangsrika. 

Av de olika faktorer som 
bidrar till avbrutna och pa 
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andra satt misslyckade projekt 
ar den storsta ofullstandiga 
krav, med 13,1 procent. 

Kort sagt, forbattrad krav¬ 
hantering horde vara prioritet 
nummer ett for att forbattra 
systemutveckling. 

det har gjorts fler undersok- 
ningar efter den som beskrivs 
ovan och en del visar pa vissa 
forbattringar. 

Men i de fiesta fall beskrivs 
fortfarande grader av miss- 
lyckanden som inte borde vara 
acceptabla. 

2006 presenterade Info-Tech 
Research Group en undersok- 
ning som visar att 50 procent 
av allt merarbete i utvecklings- 
projekt beror pa problem med 
kravhantering. 

70 procent av de misslyckade 
projekten misslyckas pa grund 
av dalig kravhantering. 

I en annan rapport samma ar 
fran Info-Tech fastslas det att 
det kostar 10 - 100 ganger mer 


GB IBM dominerar 

Marknadsandelar kravverktyg 2006. 

Se ( rena MKS 
Software 0 3% 

Ovriga — 0 

15,2% x 


S3 IBM okar annumer 

Marknadsandelar kravverktyg 2007. 
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Kalla: Gartner 


Kalla: Gartner 


EN JATTE DOMINERAR. IBM ar den klart dominerande aktoren pa marknaden for kravverktyg. Det blev extra 
tydligt efter att it-jatten forvarvade den storsta konkurrenten, svenska Telelogic. Bland uppstickarna marks 
Borland som traditionellt varit starka pa utvecklingsverktyg. 


att atgarda ett problem som hit- 
tas under testning av ett system 
an att atgarda ett problem som 
hittas under arbetet med krav¬ 
hantering. 

DET ar INGEN raketforskning att 
konstatera att kravhantering ar 
oerhort viktigt. 


STOR MARKNAD 


Aven om kravhantering inte 
uppmarksammas sa mycket tror 
analytiker anda att intresset 
kommer att oka. 

Gartner uppskattar att 
marknaden for kravverktyg 
kommer att oka mer an tio 


procent per ar fran 2008 till 
2012 . 

I pengar innebar det en okning 
fran 200 miljoner dollar, cirka 
1,7 miljarder kronor, 2008 till 
mer an 300 miljoner dollar, 
cirka 2,5 miljarder kronor, 2012. 



THINK 


.. 


Illi 

1111 


llll 


SAMVERKA KRINGI 
KRAVFANGST MED 
REQUIREMENTS COMPOSER 


Med IBM Rational Requirements Composer kan^Nlw ^ 
kravstallare och utvecklingsteam definiera kraV^N &Z^ - + ' ^ 
med hog kvalitet genom samverkan. Affarsmal 
kan preciseras genom att kombinera visuella ^ 

ffft? v 


och textuellatekniker. 


Vill du veta mer om Rational Requirements 
Composer? Ga in pa 

ibm.com/software/awdtools/rrc 


Rational 


software 


IBM, IBM-logon, Rational och ibm.com ar registrerade varumarken som tillhor International Business Machines Corporation i USA och/eller andra lander. En aktuell lista over IBMs varumarken finns under "Copyright and trademark information” pa ibm.com/legal/copytrade.shtml. 
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Kravhantering i ett notskal 


Du har en massa behov. Du vill 
uppfylla dem med ett it-sys- 
tem. Later det svart? Till din 
hjalp har du en process som 
kallas kravhantering. 


JENNY STADIGS 

jenny.stadigs@idg.se 

Kravhantering ar den process 
som ska leda till att ett it-system 
uppfyller de behov som intres- 
senterna har. Hur det har ska 
ga till for att ge basta mojliga 
resultat finns det skilda upp- 
fattningar om. 

- Kravhantering betyder 
manga olika saker for manga 
olika mannis- 
kor, sager Robin 
Bater, kravhan- 
teringsexpert 
pa IBM. 

De delmo- 
mentsomoftast 
ingar i kravhan- 
teringsproces- 
sen ar behovsanalys och kra- 
vinsamling samt prioritering, 
dokumentation, kvalitetssak- 
ring och godkannande av kra- 
ven. Kravhanteringsprocessen 
tacker aven in leverans och 
forvaltning av it-systemet. Hur 
processen genomfors beror del- 
vis pa vilken utvecklingsmetod 
man anvander sig av. 

CHRIS hofstetter, utbildnings- 
chef pa Konsultbolagl, hjalper 
foretag att finna fungerande 
former for sin kravhantering. 




Bchovsanalvs 


jdkannande 


- For mig innebar kravhan¬ 
tering att skapa forutsattningar 
for losningar som motsvarar 
behov, sager han. 

Att likstalla kravhantering 
med att dokumentera onska- 
de losningar ar vanligt bland 
bestallare av it-system, enligt 
Chris Hofstetter. 

- Det ar lite av en fara. Doku- 
mentationen ar bara en liten del 
avkravhanteringen och inte ens 
den viktigaste. 

tonvikt pa dokumentation leder 
aven ofta till ett annat vanligt 
problem: att man lagger for 
mycket fokus pa losningar och 
darmed glommer bort de bak- 
omliggande behoven. 

- Det blir ofta misslyckat om 


vi kommer till leverantoren med 
en fardig losning. Vi maste kun- 
na kommunicera behoven. Pa sa 
satt kan leverantorens kunskap 
om tekniken kombineras med 
bestallarens kunskap om verk- 
samheten. 


chris hofstetter ser darfor krav- 
dialogen som 
den viktigaste 
delen av krav¬ 
hanterings¬ 
processen. Det 
finns en rad oli¬ 
ka tekniker for 
att underlatta 
kommunika- 


i 

m 


Chris 

Hofstetter. 


tionen, exem- 
pelvis kan bilder anvandas. 

- Det handlaromenkla bilder 


FLERA KRAVSTALLARE 


Det ar inte bara de som ska 
anvanda systemet som bor 
vara med och stalla krav pa 
it-systemet. Det finns en lang 
rad olika intressenter att ta 
hansyn till, exempelvis: 

De som ska ta hand om sys- 
temdriften. 

Andra system. 

De som ska salja systemet. 
Myndigheter som utfardar 
olika regler och forordningar. 


som hjalper oss att forsta vad vi 
egentligen pratar om. Bilden 
i sig ar inte viktig, utan det ar 
dialogen om bilden som ar det 
centrala, sager Chris Hofstet¬ 
ter. 

DET FINNS OLIKA drivkrafter bak- 
om kravhanteringsprocessen. 
Den starkaste ar naturligtvis 
att skapa ett it-system som ar 
bra for affarerna, enligt Robin 
Bater pa IBM. 

- Men det kan aven finnas till 
exempel regelefterlevnadskrav 
som paverkar hur kravhante- 
ringen skots, sager han. 

Ett annat mal med kravhan- 
teringen kan helt enkelt vara 
att fa battre overblick over ett 
projekt. 

- Kravhantering kan se ut pa 
manga olika satt. Du kan antin- 
gen vara valdigt strikt, eller 
mindre formell. Ratt niva beror 
pa vilka mal du har, sager Robin 
Bater. 




think X 


11:11:11 




DEVELOPERWORKS - IBMS TEKNISKA 
RESURS FOR UTVECKLARE - UTOKAS 
MED SOCIALA NATVERKSVERKTYG 


Besok My deveioperWorks pa ibm.com/developerWorks/mydeveloperworks 

I IBM, IBM-logon, Rational och ibm.com ar registrerade varumarken som tillhor International Business Machines Corporation i USA och/eller andra lander. En aktuell lista over IBMs varumarken finns under “Copyright and trademark information” pa ibm.com/legal/copytrade.shtml. 
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Usel kommunikation 

sanker projektet 




En vanlig orsak till att kravhantering 
fallerar ar brist pa kommunikation. 
Personer som inte sager sin asikt 
samt missforstand ar recept pa att fa 
projekt att misslyckas belt. 


”Det behovs synpunkter 
fran alia avdelningar 
som kan tankas 
komma i kontakt 
med systemet” 


TEXT: 

JOELWESTERHOLM 

ILL: 

DENIZ KAYA 



ETT MOTE SOM BLIR fel ar en av 

de vanligaste orsakerna till 
varfor it-projekt misslyckas, 
enligt Soren Ravnskov, vd pa 
Astrakan Strategisk Utbild- 
ning. 

Det galler sarskilt under 
arbetet med kravstallning. 

- Det handlar mycket om 
kommunikation. Manniskor 
kommunicerar valdigt olika, 
sager Soren Ravnskov. 

De stora problemen, som 
Soren Ravnskov tar upp, ar 
dels att medarbetarna inte 
forstar varandra och cheferna, 
dels att de medverkande inte 
tar ansvar och funderar pa om 
de gor ratt saker. 

- Alldeles for fa stannar 
upp och reflekterar over ”hur 
hjalper det har att uppna vara 
projektmal”. Det vore jattebra 
om medarbetare ifragasatte sa 
att de inte gor saker som inte 
behover goras. 

det behovs en tillatande kultur 
inom ett projekt. 

En chefs storsta misstag ar 
att forsoka hitta personer att 
skylla pa nar nagot gar fel. 

Det ar inte intressant att 
hitta syndabockar utan det 
viktiga ar att fortsatta gora det 
som ska uppnas. 

- En grundregel ar att kom- 
municera tio ganger mer och 
satta av tid for att prata om 
hur man kan driva projektet 
framat. 

JOHAN HOKENHAMMAR, vd pa 

Projektstegen, anser att det 
storsta problemet ar att vissa 
intressenter inte involveras 
overhuvud taget. 

Bestallaren lagger ofta all 
kraft pa att fa fardigt forsta 


versionen som uppfyller de 
direkta kraven - utan att tanka 
pa hela livscykeln. 

Bestallaren ska i stallet ta 
dnskemalet, som oftast kom- 
mer uppifran i bolaget, och 
vara stark nog for att bredda 
det sa att aven de icke funktio- 
nella kraven tillgodoses. Det 
kan till exempel galla flexibi- 
litet, sakerhet eller att kunna 
ateranvanda koden. 

Det behovs synpunkter fran 
alia avdelningar som kan tan¬ 
kas komma i kontakt med sys¬ 
temet. 

- for det forsta maste bestal¬ 
laren rannsaka sig sjalv och 
se om han eller hon ar en bra 
bestallare. Det racker inte att 
tro det bara for att han eller 
hon ar chef. Bestallaren har ett 
ansvar att lata alia intressenter 
komma till tals. Det gar inte att 
lagga over hela kravarbetet pa 
it-avdelningen. 

Det projekt som lagger all 
kraft pa att fa fardigt forsta 
versionen kostar mer i lang- 
den. 

Enligt JohanHokenhammar 
ar det de icke funktionella kra¬ 
ven som blir dyra att atgarda i 
efterhand. 

Skapandet av systemets for¬ 
sta version utgor bara en brak- 
del av totalkostnaden. 


LETAINTESYNDABOCK 


Soren Ravnskov anser att 
den vanligaste fallgropen 
ar kraften som gar at till att 
hitta syndabockar nar nagot 
gar fel. Vid problem galler 
det att ga vidare och direkt 
hitta tillbaka till de mal som 
ska uppnas. 
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Ledarskap nyckeln till framgang 


For att kravhantering ska 
lyckas maste alia involveras 
och budskapet maste ga fram. 
For det behovs ett tydligt 
ledarskap och en kultur 
som alia vagar ifragasatta. 


JOEL WESTERHOLM 

joel.westerholm@idg.se 

Tord Schultz, vd pa Sentensia Q, 
anser att det forsta som maste 
goras ar en nyttoanalys och att 
nagon pekas ut som formellt 
ansvarig for att vardena i analy- 
sen uppnas. Nasta steg ar att se 
till att alia blir involverade. 

-Alla maste vara med pa 
banan och forsta vad man gor 
i projektet. Det ar viktigt att ta 
den har dialogen initialt och att 
alia forstar att de ar delaktiga, 
sager Tord Schultz. 


Eftersom det har ar en vasent- 
lig del av sjalva kravstallningen 
galler det att inte tumma pa 
detaljerna. Under projektets 
gang maste man standigt sitta 
ner och stamma av vad man 
kommit fram till. 

- Jag forsoker jobba mycket 
med workshops. Jag tror att det 
ar ett bra arbetssatt. 

for att undvika problemet med 
att manniskor inte talar samma 
sprak anser han att en bra metod 
ar att hitta andra satt att presen- 
tera information. 

- Det ar bra att anvanda andra 
former an skriftlig information. 
En del behover stod i visualise- 
ringar och bilder for att forsta. 
Jag tror ocksa att det ar en bra 
metod om man kan arbeta med 
modeller. 


Goran Hollsten, seniorkon- 
sult pa Influ¬ 
ence, lyfter 
fram chefens 
roll i projektet. 

Problem skylls 
oftapatekniken 
men orsaken ar 
oftast bristande 
ledarskap. 

- Det beror 
nastan alltid pa att chefen inte 
ar tillrackligt auktoritar utan 
kor den demokratiska ledarsti- 
len. All forskning visar att man 
behover vara auktoritar for att 
skapa ratt samarbetskvalitet. 

hemligheten ar att kunna karma 
av nar det ar lage att vara aukto¬ 
ritar och nar det ar lage att vara 
handledande. En annan viktig 
punkt ar att hela tiden arbeta 


ARBETA MED KVITTENS 


For att sakerstalla att alia 
personer kommunicerar pa 
samma satt anser Goran Holl¬ 
sten att man ska arbeta med 
kvittens. 

Det innebar att efter att du 
som ledare gett en anstalld 
en uppgiftskadu be den 
anstallde beratta hur den har 
uppfattats. 


sa att de som inte involverar 
sig tillrackligt verkligen tar sitt 
ansvar. 

- Detjagbrukargoraarattjag 
ger alia ordet. Som medlem har 
du alltid ratten och aven skyl- 
digheten att tala. Det ar den 
formella delen. I den informella 
galler det att skapa ratt klimat i 
projektet. 



THINK 


HANTERA DITT INFORMATIONSKAOS MED 



RATIONAL FOCAL POINT 


Kaos bland e-post, dokument och kalkylblad. 
Kanner du igen det? Sa behover det inte vara. 

Med IBM Rational Focal Point blir det enklare att 
hantera informationskaoset. Unika funktioner for 
prioritering och visualisering gor att du kan 
maximera kundnyttan i forhallande till 
kostnaderna for utveckling. 

Med Rational Focal Point kan du fatta battre och 
snabbare beslut, och tack vare det fokusera din 
utveckling till de mest vardefulla behoven, kraven, 
projekten och produkterna. 

ibm.com/software/awdtools/focal point 


Rational. 


software 



IBM, IBM-logon, Rational och ibm.com ar registrerade varumarken som tillhor International Business Machines Corporation i USA och/eller andra lander. En aktuell lista over IBMs varumarken finns under "Copyright and trademark information” pa ibm.com/legal/copytrade.shtml. 
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Mycket planering 
for bra kravhantering 




Med felaktig kravhantering okar 
risken att fel krav samlas in fran fel 
intressenter med hjalp av fel tekniker. 
Det sager Ulf Eriksson, forfattare till 
boken Kravhantering for it-system. 


”Ett viktigt syfte med att 
prioritera krav ar att 
identifiera de krav som 
ger mest varde for peng- 
arna respektive de krav 
som ar forknippade med 
storst risker” 


TEXT: 

JOEL ASBLOM 

ILL: 

KJELL ERIKSON 


ulf eriksson har i sin roll som 
senior testledare pa Konsult- 
bolagl fatt folja en rad projekt 
inom kravhantering i flera 
branscher och sammanfattat 
sina basta rad i boken Krav¬ 
hantering for it-system. 

Hans slutsats ar att brister i 
kraven ar den storsta felkallan 
vid utvecklingen av it-system. 

- Nar man bygger ett system 
behover man samla in krav fran 
intressenter som ar represen- 
tativa for verksamheten. Det 
bor goras i form av en sa kallad 
intressentanalys i vilken man i 
workshopform listar tankbara 
intressenter och beskriver vad 
intressenten vill ha fran pro- 
jektet respektive vad projektet 
vill ha fran intressenten, sager 
Ulf Eriksson. 

MED INTRESSENTER menar han 
kunder, anvandare, driftorga- 
nisationen och testare. 

- Om man upptacker for 
sent att man missat krav fran 
driftorganisationen blir det 
dyrt att andra systemet. 

Sedan finns det en rad olika 
krav som behover fangas in. 

- De funktionella kraven 


beskriver funktioner som 
anvandarna ser eller har nytta 
av. 

- De icke-funktionella kra¬ 
ven beskriver anvandbarhet, 
tillforlitlighet, prestanda och 
forvaltningsbarhet, sager han. 

AVEN ICKE-FUNKTIONELLA aspek- 
ter ar viktiga att fanga sa tidigt 
som mojligt, anser han. 

- Det finns aven andra krav 
som behover identifieras, till 
exempel de forvantade kraven, 
krav som maste lasas in mellan 
raderna. Det finns aven sensa- 
tionella krav som overtraffar 
intressentens forvantan och 
som leder till att man levererar 
ett mervarde. 

For att fanga 
sa manga 
typer av krav 
som mojligt 
behovs olika 
kompletteran- 
de insamlings- 
tekniker. 

-Det arvan- 
ligt att fanga krav med tekni¬ 
ker som workshops, intervjuer 
och enkater, men risken med 
dessa tekniker ar att man mis- 



SYSTEMATISERA DIN 
VERKSAMHETSUTVECKLING, 
OCH UPPNA BATTRE RESULTAT 


Med Measured Capability Improvement Framework (MCIF) far du ett 
systematiskt tillvagagangssatt for verksamhetsutveckling. 

Ladda ner vart e-Kit och se hur du kan effektivisera din verksamhetsutveckling 



think JJljlljj 


IIHI 


Rational 


software ibm.com/software/rational/announce/mcif 


IBM, IBM-logon, Rational och ibm.com 


ar registrerade varumarken som tillhor International Business Machines Corporation i USA och/eller andra lander. En aktuell lista over IBMs varumarken finns under "Copyright and trademark information” pa ibm.com/legal/copytrade.shtml. 
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Kravhantering lyft 
for Lufthansa 



sar de forvantade och de sensa- 
tionella kraven. 

Vanliga kompletterande tek- 
niker ar anvandningstester och 
observation som gar ut pa att 
man studerar en anvandare som 
utfor uppgifter i systemet. 

ulf eriksson pekar aven pa vik- 
ten av att prioritera bland de 
krav som ska stallas. 

- Ett viktigt syfte med att 
prioritera krav ar att identifiera 
de krav som ger mest varde for 
pengarna respektive de krav 
som ar forknippade med storst 
risker. Darmed kan man valja 
vilka krav som ska realiseras 
forst och vilka krav som kan 
skjutas pa framtiden. 

I arbetet med kravhantering 
ar dokumentation ett ofta efter- 
satt omrade som ar viktigare an 
det later. 

- Dokumentationen ar under¬ 
lag for alia kommande utveck- 
lings- och testaktiviteter och 
kan ses som ett formellt kon- 
trakt mellan bestallare och leve- 
rantor, sager Ulf Eriksson. 


SENIORKONSULT 


Ulf Eriksson ar seniorkonsult 
inom kravhantering och test 
pa Konsultbolagl i Stockholm. 
Han ar en valkand forelasare 
och utbildare och 
har skrivit bock- ’ ^ 

erna Kravhanter- 

I *" ej f. 

ingfor it-system 
och Test och 

kvalitetssakring i * 
av it-system. 

Han arbetade fran borjan 
med verksamhetsutveckling i 
forsakringsbranschen och gick 
senare over till programmer¬ 
ing. De senaste tio aren har 
han arbetat uteslutande med 
kravhantering och test, i bade 
ledande och utforande roller. 
Ulf ar en av tva grundare av 
Konsultbolagl, ett foretag 
nischat pa test och kravhante¬ 
ring. 

»> Ulf Erikssons Konsultbolagl 
har samlat fakta om krav¬ 
hantering pa 

konsultbolagl.se/faktabanken 


Undersokningar visar att cirka 
halften av alia havererade 
mjukvaruprojekt beror pa 
felaktig kravhantering. 
Flygbolaget Lufthansa ar val 
medvetet om det och satsar 
stort pa kravhantering. 


JOEL ASBLOM 

joel.asblom@idg.se 

Analysforetaget Standish Gro¬ 
up har nyligen genomfort en 
undersokning av 300 projekt 
hos biltillverkare, telekombolag 
och flygforetag. 

Den visar att mellan 40 till 
60 procent av felen som upp- 
dagades i systemen berodde pa 
felaktiga kravspecifikationer. 
Rapporter av det har slaget har 
bidragit till ett okat intresse for 
kravhantering, vilket tyska Luft¬ 
hansa ar ett exempel pa. 

lufthansas programdivision, 
Systems Industry Solutions, har 
nu infort helt nya processer for 
programutveckling. 

Foretagets projektchef Jutta 
Schwaag berattar att man han- 
terar 6 000 olika programkom- 
ponenter och darfor tvingats 
styra utvecklingen med kraft- 
fulla verktyg. 

- Det stalls enorma krav pa 
komplexa program av det har 
slaget. I borjan av utvecklingen 
ar anvandarnas kravspecifika¬ 
tioner oftast valdigt begran- 
sade och darfor ar det viktigt 
att sa tidigt som mojligt borja 


specificera dessa, sager Jutta 
Schwaag. 

lufthansas bakomliggande sys¬ 
tem for programhanteringheter 
MDA Generator Andromda i 
vilket det ingar 2 500 program- 
kategorier. 

For sjalva kravhanteringen 
foil valet pa Borlands verktyg 
Caliber RM eftersom det ar till- 
rackligt brett for att omfatta alia 
de produkter som ska levereras 
fran flygbolagets tredjepartsut- 
vecklare. 

Dessutom jobbade Lufthansa 
sedan tidigare med produkten 
Borland Together Designer for 
analys och utveckling. 

- Resultatet av reformerna 
ar att vi nu inte bara far battre 
styrning pa programutveck- 
lingen utan aven kontinuerligt 
kan kontrollera kapacitetspla- 
neringen i flygfrakterna, sager 
Jutta Schwaag. 


KRAV SPELAR ROLL 


I en undersokning av Standish 
Group granskades 300 projekt 
hos biltillverkare, telekom¬ 
bolag och flygforetag. 

Mellan 40 och 60 procent av 
felen som hittades i fardiga 
system berodde pa felaktiga 
kravspecifikationer. 

Foretag som de undersokta 
anvander ofta valdigt manga 
program som hanger ihop, 
vilket gor kravhantering extra 
svart. 


Tidningen du vet att du behover! 


www.computersweden.se/prova 
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Lat kraven hanga 
med hela vagen 




Det ar viktigt med en fungerande 
kravhanteringsprocess under ett 
systems iivscykel. Chanserna okar att 
fa ett system som fungerar felfritt 
och som aven fyller verkliga behov. 


”Vi maste ha med 
forvaltningstanket 
redan fran borjan. Den 
stora dolda kostnaden 
for it-system ligger 
i forvaltningen” 


TEXT: 

JENNY STADIGS 

ILL: 

KJELL ERIKSSON 


BEHOV - EN FARSKVARA 


Vara behov och prioriteringar ar farskvaror 
som helatiden andras. 

Det ar en av orsakerna till att det inte ar en 
god i ide att bara gora en statisk lista med 
hundratals eller tusentals krav som sedan 
implementeras i ett system. 

Under systemets Iivscykel tillkommer nya 
krav, andra krav andras, och vissa krav tas 
bort. Paverkan av det i systemet ar svar- 
overskadlig utan en tydlig kravprocess som 
hanger med under systemets hela Iivscykel. 


kravhantering for it-system 
har funnits i nagon form lika 
lange som systemen sjalva. 
Men synen pa vad kravhan- 
teringsprocessen bor omfatta 
har andrats. Allt fler propage- 
rar nu for hur viktigt det ar att 
kraven hanger med i hela pro- 
jektet, anda fram till drift och 
underhall. 

- Ofta lagger vi massa kraft 
pa kravhantering i utveck- 
lingsprojekt. Men vi glommer 
att ta fram en process som ar 
enhetlig i bade projekt och for- 
valtning, sager Chris Hofstet- 
ter, utbildningschef pa Kon- 
sultbolagl som specialiserat 
sig pa kravhantering och test 
av it-system. 

KRAVHANTERINGSPROCESSEN 

bestar av ett antal delmoment: 
behovsanalys och kravinsam- 
ling samt prioritering, doku- 
mentation, kvalitetssakring 
och godkannande av krav. 

- Den har processen bor 
egentligen vara precis den- 
samma i forvaltningen. Men 
ofta bygger vi till nya funk- 
tioner i system utan att krav- 
hanteringsprocessen har gatts 
igenom. 

Det kan fa ett flertal nega- 
tiva foljder, bland annat ar 
det vanligt att det uppstar fel 
i system som upptacks valdigt 
sent i utvecklingsprocessen 
om kvalitetssakring av kraven 
inte har gjorts. 

Chris hofstetter menar att det 
ar vanligt med vattentata skott 
mellan projektorganisation 
och forvaltningsorganisation. 

- Overlamningen fran nyut- 
vecklingen till dem som ska 
forvalta system ar valdigt vik- 


tig. Det maste finnas lite over¬ 
lapping, projektgruppen far 
inte bara forsvinna. 

Det ar aven nodvandigt att 
forvaltare ar med i nyutveck- 
lingen och deltar i kravstall- 
ningen. 

- Vi maste ha med forvalt¬ 
ningstanket redan fran borj an. 
Den stora dolda kostnaden for 
it-system ligger i forvaltning¬ 
en. 

dokumentation ar en annan 
viktig del nar det galler livscy- 
kelhanteringen. 

- Det maste finnas doku- 
mentation om system, annars 
ar det mycket 
svart att for¬ 
valta. Agila 
projekt ar ofta 
valdigt bra, 
men en nack- 
del med dem 
ar att de ar lite 
tunna i doku- 
mentation. 

Kunskap om hur system 
hanger ihop och vilka behov 
som ligger till grund for dem ar 
nodvandig for en framgangs- 
rik forvaltning, anser Chris 
Hofstetter. 

-Jag maste forsta hur en 
andring av systemet paverkar 
kringliggande delar av det 
och hur mycket jag behover 
testa. 

aven robin bater, kravhante- 
ringsexpert pa IBM, anser att 
det ar mycket viktigt att se till 
att kraven hanger med i hela 
projektet, anda fram till drift 
och underhall. 

- Aven nar systemet ar klart 
kommer det att fortsatta att 
forandras, sager han. 
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Kraven hos Afa ar kvar 
tills systemen skrotas 


Involvera verksamheten redan 
fran borjan och se till att 
vidareutveckling av systemen 
inte blir ett ostrukturerat 
snabbfixande. Det ar nagra av 
Afa Forsakrings viktigaste 
kapphastar for att lyckas med 
kravhanteringen under ett 
it-systemets hela livscykel. 


JENNYSTADIGS 

jenny.stadigs@idg.se 

Att fa till en fungerande krav- 
hanteringsprocess som hanger 
med under hela it-systemets 
livscykel ar inte det lattaste. 
Afa Forsakring ar ett av de fore¬ 
tag som satsat hart pa att lyckas 
med det. 

- Vi har egenutvecklade 
system som ar 
stora och kom- 
plexa och som 
har en relativt 
lang livslangd. 
Vi maste ha 
en fungerande 
kravhantering 


Patrik Melin. 


cykeln for att 
kunna vidmakthalla och utveck- 
la systemen och fa tillbaka den 
investering vi gjort, sager Patrik 
Melin, chef for verksamhetsut- 
veckling pa Afa Forsakring. 

Foretaget har tagit fram en 
egen iterativ utvecklingsmetod 


som baseras pa Rup. I den ingar 
en tydlig modell for kravhante¬ 
ring. 

- Vi gor det som behovs och 
inget mer. Det handlar om att 
identifiera kraven som fyller 
behoven som verksamheten 
har och att sedan gora en tydlig 
overenskommelse med bestal- 
laren. 

ambitionen ar att kraven ska vara 
sa bra beskrivna och dokumen- 
terade att de gar att ateranvanda 
rakt av vid test och kvalitetssak- 
ring av systemet. 

Det allra viktigaste for en god 
livscykelhantering ar att invol¬ 
vera och engagera verksamhe¬ 
ten redan fran start, enligt Pat¬ 
rik Melin. 

- For att lyckas med det gal- 
ler det att prata verksamhetens 
sprak och att inte ha for hog 
ambitionsniva i borjan. 

En annan mycket viktig del av 
Afa Forsakrings lyckade arbete 
med kravhantering ar en uttalad 
strategi att bemanna nyutveck- 
lingsprojekten med individer 
som senare kommer att tillhora 
forvaltningsorganisationen. 

-Vi tar in externa resurser 
som ersattare i forvaltnings¬ 
organisationen under tiden om 
det behovs. Eftersom de inter¬ 
na medarbetarna ska vara med 
och forvalta systemet senare sa 




blir overlamningen naturligare 
genom att vi gor sa har. 

nar det galler vidareutveckling 
av det fardiga systemet ar Afa 
Forsakring noga med att for- 
soka periodisera arbetet och 
gora det sa projektlikt som 
mojligt. 

- Vi stravar efter att undvika 
ad hoc-utveckling och forsoker 
i stallet att gora ungefar fyra 
storre nyreleaser per ar. 

Den framsta orsaken till det 
har arbetssattet ar att kvalitets- 
sakringen ska bli sa kostnads- 
effektiv som mojligt. 

- Det blir valdigt dyrt om man 


550 MEDARBETARE 


Afa Forsakring forsakrar 
anstallda inom den privata 
sektorn, kommuner och 
landsting och ger ekonomiskt 
stod vid arbetsbrist, sjukdom, 
arbetsskada och dodsfall. 

En viktig del av verksamheten 
ar ocksa att stodja forskning 
och projekt som aktivt syftar 
till att forbattra arbetsmiljon. 
Organisationen ags av 
Svenskt Naringsliv, LO och 
PTK. 

Antalet medarbetare ar 

ungefar 550 och antalet 
forsakrade drygt 3 miljoner. 


gor manga smareleaser och dar- 
med maste testa igenom syste¬ 
met ofta. 

Med far re och storre nyre¬ 
leaser undviker Afa Forsakring 
aven att systemen blir till lapp- 
tacken av snabba fixar utan en 
genomtankt grundstruktur. 

detar inte alltid latt att forklara 
fordelarna med det har arbets¬ 
sattet for anvandarna. 

- De vill ofta ha andringarna 
valdigt fort och det ar klart att 
de inte alltid tycker om att fa 
vanta. Men om det ar stora fel 
sa fixar vi naturligtvis direkt, 
sager Patrik Melin. 


!!!!!! think 


ii-'-ii 


NYSKAPANDE PROGRAMUTVECKLING GENOM 
SAMARBETE - RATIONAL TEAM CONCERT I 


IBM Rational Team Concert ar en samverkansmiljo for leverans av programvara 

Rational Team Concert okar teamets formaga genom integrerade arbetsobjekt 
byggen, software configuration management (SCM) och infrastruktur 
genom samverkan i en Jazz Team Server. 



Rational 


software 


Mer om Rational Team Concert kan du lasa pa ibm.com/software/awdtools/rtc 


IBM, IBM-logon, Rational och ibm.com ar registrerade varumarken som tillhor International Business Machines Corporation i USA och/eller andra lander. En aktuell lista over IBMs varumarken finns under “Copyright and trademark information” pa ibm.com/legal/copytrade.shtml. 
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Se upp for olika viljor 




Gamlingen Rup, rutinerade Scrum och 
uppstickaren dsdm - CS hjalper dig 
att valja utvecklingsmetod beroende 
pa hur kravhantering skots i de olika 
metoderna. 


”Da kravhanterings- 
processen ar en av de 
viktigaste bitarna i 
utvecklingsprojekt ar 
det viktigt att veta 
hur de olika metoderna 


skiljer sig at i det 
avseendet” 


TEXT: 

PETER LARSSON 

ILL: 

KJELL ERIKSSON 



Scrum dsdm 


Hmm, 


I BAKVATTNET EFTER vattenfalls- 
modellen har det kommit en 
uppsjo av olika utvecklings- 
metoder. Vissa av dem ar latt- 
rorliga, andra lite stelare. Da 
kravhanteringsprocessen ar en 
av de viktigare bitarna i utveck¬ 
lingsprojekt ar det viktigt att 
veta hur de olika metoderna 
skiljer sig at i det avseendet. 

Till att borja med skots krav- 
insamlingen pa nagot olika 
satt. I Scrum finns formodli- 
gen den bredaste ansatsen. 

- Krav samlas in med alia 
till buds staende medel, sager 
Tobias Fors, Scrumexpert pa 
Citerus. 

Rup och dsdm innehal- 
ler inga begransande regler 
for kravinsamlingen, men 
de vanligaste satten ar inter- 
vjuer, prototyper, bildmanus, 
anvandningsfall och proces- 
skisser, alltsa satt som lange 
varit praxis vid kravinsamling, 
oavsett utvecklingsmetod. 

vilka svarigheter finns da att 
overvinna i kravinsamlingen i 
respektive utvecklingsmetod? 
Rup brottas med nytillkomna 
krav under projektets gang. 

- Det kan hanteras genom 
att ha en formed beslutspro- 
cess som styr vilka krav som 
ska in eller inte, sager Micha¬ 
el Pettersson, Rupexpert pa 
Sogeti. 

Dsdm har problem med att 
det tidigt i projekt inte gar att 
borja bocka av krav som reali- 
serats. 

- Det kan goras forst en bit 
in i projektet da utveckling och 
test ar fullt produktiva, sager 
Martin Volcker, dsdm-konsult 
pa Suit. 

Han tillagger att frageteck- 
en runt detta bor forklaras for 
verksamheten, sa att arbetet 
darmed forenklas. 

Tobias Fors sager att krav¬ 
insamlingen alltid praglas av 
manga olika intressenter med 
olika viljor och prioriteringar. 
Scrums produktagarroll forso- 


ker uppna ett tydligt agarskap 
for den overgripande kravbil- 
den och for prioriteringar. 

- De manga viljorna kombi- 
nerat med en foranderlig mal- 
bild staller formidabla krav pa 
den eller de som arbetar med 
kravbilden, sager Tobias Fors. 

ansvaret for att krav formali- 
seras ligger pa olika personer, 
beroende pa utvecklingsme¬ 
tod. I Rup har den ansvarige 
titeln systemanalytiker. 

I dsdm ar anvandarambas- 
sadoren tillsammans med 
visionaren, bada fran bestal- 
larsidan, som delar pa ansva¬ 
ret for kravformaliseringen. 

- Projektgruppen ger sedan 
stod for hur man ska gora da 
verksamhetsrepresentanter- 
na ofta saknar kunskap om hur 
det ska ga till. Testledaren ar 
ocksa central i arbetet da den 
personen rapporterar status 
for funktioner och dess kva- 
litet i olika leveranser, sager 
Martin Volcker. 

I SCRUM ar det friare. Enligt 
Tobias Fors ar kraven i Scrum 
sa formella eller informella 
som situationen kraver. 

- Det ar skillnad pa enkla 
webblosningar och mjukvara 
for maskiner som anvands for 
cancerbehandling, sager han. 
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Sa forstar du anvandarnas krav 


Fa saker ar sa svara att forsta 
som vad folk egentligen vill ha. 
Har ar losningarna som under- 
lattar kommunikationen med 
systemanvandarna och som 
ger battre mjukvara. 


PETER LARSSON 

peter.larsson@idg.se 

Det finns tva stora problem nar 
det ar dags att samla in krav. 

- Folkkommunicerarinte over 
organisatoriska granser och de 
pratar inte samma sprak, sager 
Lotta Hugner, kravexpert och 
konsultchef pa konsulten Guide. 

Det forsta kan losas genom att 
samla personer fran olika delar 
av organisationen i grupper 
under kravinsamlandet. 

- Kravinsamlinggors bast i en 
workshop. Det ar det mest krea- 
tiva sattet och deltagarna hj alper 
varandra med tankandet, sager 


Johan Wreto, kravspecialist pa 
utbildningsforetaget Astrakan. 

Sprakforbistring leder ovill- 
korligen till begreppsforvir- 
ring och tas om 
hand genom 
anvandandet av 
modeller. Exem- 
pel pa sadana ar 
domanmodell, 
en modell over 
de funktionella 
och icke-funk- 
tionella kraven. 

- Modeller gor kraven tydli- 
gare, sager Lotta Hugner. 

anvandarna maste tidigt komma 
fram till vilket resultat de vill 
uppna. Da ar det lattare att prio- 
ritera kraven och fokusera pa det 
som ar viktigast. 

Johan Wreto halier med Lotta 
Hugner om vikten av att undvika 
begreppsforvirring. Han tillag- 


ger att det ar angelaget att und¬ 
vika tekniska termer. 

-Anvand ord som anvanda- 
ren forstar och kan relatera till, 
sager Johan Wreto. 

En av de viktigaste delarna i 
kravinsamlingen ar att ta reda 
pa vilka roller som ska anvanda 
systemet och definiera dem. 

Johan Wreto varnar for att 
det ar vanligt att manniskor 
missuppfattar hur kravinsam- 
lingstekniken anvandningsfall 
ska anvandas. De ar inte till 
for att beskriva hur systemet 
ska se ut pa skarmen eller utga 
fran ett gammalt befintligt sys¬ 
tem. Anvandningsfall ar enkelt 
uttryckt korta beskrivningar av 
hur nagot utfors. 

- Det finns manga satt att gora 
anvandningsfall daliga. Overar- 
beta dem inte, och hoppa over 
tekniska detaljer, sager han. 

Anvandningsfall ska enbart 


TIPS PA VAGEN 


Ett satt att underlatta kom¬ 
munikationen mellan bestal- 
lare och leverantor ar att 
anvanda kvittering: lever- 
antoren bekraftar varje krav 
fran bestallaren genom att 
beskriva en tankt losning. 
Andra tekniker ar dokument- 
granskning, anvandning av 
prototyper och ett gemensamt 
verktyg for lagring av krav- 
dokumentation. 


beskriva manniskors interak- 
tion med systemet sa att man¬ 
niskor kan forsta den. 

Men det ar inte bara anvand¬ 
ningsfall som missbrukas som 
kan stalla till det. Det galler 
ocksa att samla ratt krav. Det 
ar inte omojligt att systemet 
delvis ska ersatta de manni¬ 
skor som kommer med kraven 
och da ar det avyttersta vikt att 
fundera over hur intresserade 
manniskor ar att bidra. 



THINK 


© 



HANTERA KRAV VID UTVECKLING 



AV KOMPLEXA SYSTEM OCH PROGRAM 
MED RATIONAL DOORS 


software 


IBM Rational DOORS ar en 
kravhanteringslosning som okar 
kvaliteten genom att optimera 
kommunikation, samarbete och 
verifiering av krav genom hela foretaget. 


Vill du veta mer om Rational DOORS? 

Ga in pa 

ibm.com/software/awdtools/doors 


Rational 


IBM, IBM-logon, Rational och ibm.com ar registrerade varumarken 


tillhor International Business Machines Corporation i USA och/eller andra lander. En aktuell lista over IBMs varumarken finns under “Copyright and trademark information” pa ibm.com/legal/copytrade.shtml. 
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Uppsjd av verktyg 
for kravhantering 




Reqtest fran Konsultbolagl, Quality 
Center fran HP och Doors fran IBM ar 
bara nagra av de hundratals verktyg 
som finns for effektiv kravhantering. 


”Det tillkommer 
hela tiden nya krav 
att ta hansyn till, 
inte minst for 
foretag inom den 
finansiella sektorn” 


ETT KRAVHANTERINGSVERKTYG 

innehaller ofta delar for att 
hantera bade krav och tester. 

Kraven skrivs in i verktyget 
och kan struktureras, granskas 
och prioriteras. 

- Ofta finns funktioner for 
testfall i samma verktyg. Nar 
testfalien laggs in i verktyget 
blir det sparbarhet mellan 
kraven och testfallen. Dar- 
med kan man exempelvis se 
vilka krav som ar lankade till 
testfallen och om det finns 
krav som saknar testfall, sager 
Ulf Eriksson, forfattare till 
boken Kravhantering for it- 
system. 

Bland de foretag som under 
senare ar utokat satsningen 
pa verktyg for kravhantering 
marks IBM som forra aret 
kopte den svenska specialisten 
pa omradet, Telelogic. 

Nar CS ber IBM ta fram en 
lista over foretagets verktyg 
blir det en ganska omfattande 
sadan. 


TEXT: 

joelAsblom 

ILL: 

KJELL ERIKSSON 


ANDREAS STEEN, teknisk chef for 
IBM Rational, placerar Ratio¬ 
nal Requirements Composer 
hogt pa listan. 

- Det ar ett krawerktyg for 
att beskriva krav textuellt och 
visuellt i form av storyboards, 
processmodeller, skisser och 
bilder. Det ar lampligt for 
definition av krav i text- och 
visuella format, sager Andreas 
Steen. 

Sedan kommer ett par verk¬ 
tyg fran Telelogics utbud for 
IBMs del. 

Rational Focal Point 
beskrivs som ett produktled- 
ningsverktyg med avancerat 
beslutsstod. Det ar lampligt 
for tidig kravinsamling med 


prioriteringsbehov och relea¬ 
seplanering. 

Rational Doors ar mest 
lampat for projekt med hoga 
krav pa sparbarhet och 
andringshantering, enligt 
IBM. 

ett av ibms mest anvanda krav- 
hanteringsverktyg ar sedan 
gammalt Rational Requisite- 
pro. 

- Har ligger fokus pa pro- 
jekt i vilka man vill arbeta med 
Worddokument exempelvis i 
form av anvandningsfall, sager 
Andreas Steen. 

Han betonar att de olika 
produkterna inte har riktigt 
samma malgrupp. 

- Det ar processen och 
inte verktygen som styr vad 
vi rekommenderar till kun- 
derna. 

Forutom renodlade verk¬ 
tyg for kravhantering finns 
det aven atskilliga andra 
som delvis fyller samma funk- 
tion. 

- Prototypverktyg som 
Microsoft Visio och Balsamiq 
Mockups kan aven vara intres- 
santa for den som jobbar med 
kravhantering. Dessutom finns 
det verktyg for att fanga krav i 
form av enkater och det finns 
andra verktyg som kan under- 
latta gransk- 

ning, sager Ulf 5 ■ l U 
Eriksson. 

ULF SANDBERG, 

Nordenchef 
pa Nohau som 
bland annat ar 
aterforsaljare 
for Borlands 
kravhante- 
ringsverktyg, 
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tycker det ar viktigt att verk- 
tygen utvecklas kontinuer- 
ligt. 

- Det tillkommer hela tiden 
nya krav att ta hansyn till, inte 
minst for foretag inom den 
finansiella sektorn. 

- Dar ar det viktigt att fa med 
det senaste kring regleringar och 
krav pa sparbarhet, sager Ulf 
Sandberg. 

han berattar att han varit med i 
”it-svangen” sedan 1974. 

- Under de senaste tio aren 
har det skett nagot av en revolu¬ 
tion pa det har omradet. Foretag 
har insett vikten av bra kravhan¬ 
tering. 

- Det ar dessutom nagot som 
paverkat hela samhallet. Saljare 
i elektronikvaruhusen har blivit 
varse att kunderna lart sig stalla 
hoga krav. 

- Inforkopetavenplatt-tvhar 
kunden med sig en lang lista av 
krav pa upplosning och annat, 
sager han. 



VERKTYG FOR KRAVHANTERING 


Har ar nagra kravhanteringsverktyg: 

Caliber-RM, borland.com 
Caliber Defineit, borland.com 
Casuite, signifikant.se 
Core, vitechcorp.com 
Cradle, threesl.com 

Enterprise Architect, sparxsystems.com 

Gatherspace, gatherspace.com 

Irqa, visuresolutions.com 

Jama Contour, jamasoftware.com 

Leap SE, leapse.com 

Lighthouse RM, artifactsoftware.com 

Open Source RM, sourceforge.net 

Optimal Trace, compuware.com 

Projectridty, projectricity.com 

Qualica QFD, qualica.de 

Rally, rallydev.com 

Rational Doors, ibm.com 

Rational Focal Point, ibm.com 

Rational Requirements Composer, ibm.com 

Rational Requisitepro, ibm.com 

RaQuest, raquest.com 

Reconcile, compuware.com 

Reqtest, konsultbolagl.se 

Reqtify, geensys.com 

Requirements Mgmt Database, reqdb.com 
Requirement Tracing System, bandwood.com 
Teamcenter, siemens.com 
Quality Center, hp.se 
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OKA KVALITETEN I 
■ I DINA PROJEKT 
MED RATIONAL REQUISITEPRO 


IBM Rational RequisitePro ar ett kravhanterings¬ 
verktyg, utformat for dig som vill skriva bra 
anvandningsfall, oka sparbarheten, starka 
samarbetet, minska riskerna och oka kvaliteten i 


dina projekt. 


Vill du veta mer? Ga in pa 

ibm.com/software/awdtools/reqpro 
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U KRAVHANTERING VERKTYG 


ComputerSweden 


MAJ 2009 


Kreativt med kort och penna 


Visst kan avancerade verktyg 
for kravhantering bringa 
ordningoch reda. Men man 
kommer langt med ordbe- 
handlare och wikisajter. Till 
och med gammaldags index- 
kort ar ett vapen i kravkam- 
pen. 


LARS DANIELSSON 

lars.danielsson@idg.se 

Tomas Cardell ar systemar- 
kitekt pa IT-Huset och har 
manga ars erfarenhet av krav¬ 
hantering. 

Ett av hans tips for att lyckas 
ar att anvanda en funktion i van- 
liga ordbehandlare som Word. 

- Anvand lankar mellan 
dokument. Da 
kan man skri- 
va de gene- 
rella kraven 
en gang och 
sedan lanka 
in dem pa alia 
stallen dar de 
behovs, sager 
han. 

Det innebar 
att man slipper bladdra mellan 
olika sidor i kravdokumenten 
och riskera att tappa traden. 

ett annat intressant verktyg 
ar wikier, alltsa webbsajter av 
typen Wikipedia. 

- Man hor ofta kommentaren 
”skriv det i wikin” under krav- 
diskussioner. Det ar viktigt att 
ha en moderator for en wiki, 
annars blir den latt vildvuxen. 


Enligt Tomas Cardell ar det 
viktigt att ha en wiki per projekt 
for att halla reda pa kraven. 

- Sedan kan man flytta 
over generell information, till 
exempel for komponenter som 
anvands av flera system, till en 
forvaltningswiki. 

YTTERLIGARE ett tankvart tips ar 
att aldrig skriva ut kravdoku- 
ment. 

- Om man har en utskrift lig- 
gande pa skrivbordet ar det latt 
att missa att onlineversionen 
har uppdaterats 75 ganger. 

En intressant utveckling 
under senare ar kommer sig av 
att lattviktsmetoder for utveck¬ 
ling av typen agile tar over fran 
mer strikta metoder som Rup. 
Eftersom dokument som figure- 
rar i agileprojekt inte ar sa hart 
klassificerade vad galler inne- 
hall sa lases de av fler personer 
i ett projekt an de avgransade 
dokumenten i ett Rup-projekt. 
Fler personer blir informerade 
om fler saker. 

- Det ar bara fordelar med 
agilemetoder. Alla far en hel- 
hetsbild. Det blir inga bra pro¬ 
jekt om de inblandade har tun- 
nelseende och bara jobbar med 
sina egna delar. 

Lite hardraget kan man sam- 
manfatta effekten med att kaos 
ger insikt. 

ulrika park, managementkon- 
sult pa Frontit, har ocksa job- 
bat med kravhantering lange. 
Det verktyg som hon namner 


forst ar vanliga indexkort. Pa 
varje kort skriver man upp en 
anvandningsberattelse i en 
mening som sammanfattar ett 
krav. 

Pa baksidan skriver man upp 
fern till tio testfall som kan 
kopplas till anvandningsberat- 
telsen. 

Eftersom det 
inte finns sa 
mycket plats 
pa indexkor- 
ten gar det helt 
enkelt inte att 
bli sa detalje- 
rad, vilket ar 
en fordel i ett 
tidigt skede av 
ett projekt. 

Kraven andras ofta under 
ett projekt sa det ar ingen vits 
att ga ner pa detaljniva direkt. 
Tvartom innebar det att det blir 
svarare att andra sig. 

- En anvandningsberattelse 
ska ses som ett lofte om en 
framtida konversation mellan 
utvecklare och kunder, sager 
Ulrika Park. 


Hur halier man reda pa de 
fysiska indexkorten? Hur ska de 
sorteras? 

- Man behover inte kategori- 
sera indexkorten utan sorterar 
dem i prioritetsordning. Man 
prioriterar kanske fern eller sju 
anvandningsberattelser i en ite¬ 
ration. 

En iteration ar arbetet med 
att skapa en ny korbar version 
av ett system och tar vanligtvis 
en eller tva veckor. 

- Det blir mer struktur pa det 
har sattet an om man bladdrar 
mellan punkt 1.7.1 och punkt 
1.7.2 i ett langt dokument. Man 
kan prioritera om utan att beho- 
va ga igenom ett hundrasidigt 
dokument, sager hon. 

- Det saknas anda en massa 
detaljer i ett sadant dokument, 
sager Ulrika Park. 


computersweden.se 


»> Las aven Han vet vad du 
gor for fel pa 

cstjanster.idg.se/e/602 


EN MENING RACKER 


En anvandningsberattelse av den typ som Ulrika Park pratar om 
i artikeln kan formuleras sa har: Som Roll vill jag kunna gora Han- 
delse for att Syfte. 

Ett exempel pa Roll ar kursadministrator. 

Ett exempel pa Handelse ar lista godkanda kursplaner. 

Ett exempel pa Syfte ar for att ge underlag till studierektorn. 
Anvandningsberattelsen blir alltsa: Som kursadministrator vill jag 
kunna lista godkanda kursplaner for att ge underlag till studierek¬ 
torn. 
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DIN WEBB KAN VARA EN SVANGDORR IN TILL 
DIN INFORMATION. AR DET INTE DAGS 
ATT SKYDDA DEN? 
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IBM Rational AppScan ar ett marknadsledande set av verktyg for 
automatiserad sakerhetsbedomning av webbapplikationer. 
Verktygen tillgodoser bl.a att krav pa uppfyllande av standards, t ex 
_.RCI, HIPPA och BASEL sakerstalls. 






m 




Las mer om hur du skyddar dina webbapplikationer pa 

ibm.com/software/awdtools/appscan 


IBM, IBM-logon, Rational och ibm.com ar registrerade varumarken som tillhor International Business Machines Corporation i USA och/eller andra lander. En aktuell lista over IBMs varumarken finns under "Copyright and trademark information" pa ibm.com/legal/copytrade.shtml. 
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Take Agile development to the next level., ^ p ^ 



Agile Manifesto 

We are uncovering better ways of developing 
software by doing it and helping others do it. 
Through this work we have come to value: 

Individuals and interactions over processes and tools 
Working software over comprehensive documentation 
Customer collaboration over contract negotiation 
Responding to change over following a plan 


That is, while there is value in the items on 
the right, we value the items on the left more. 


Explore Agile development by clicking this PDF, 
or go to ibm.com/rational/agile. 

Use the post-it notes on top as shortcuts, 
and the up and down arrows on your keyboard to zoom. 


ibm.com/rational/agile 






